Ham Radio 2000 #2

home *** CD-ROM | disk | FTP | other *** search

/ Ham Radio 2000 #2 / Ham Radio 2000 - Volume 2.iso / HAMV2 / TCP_IP / TNOS230B / NEW2TN2.20 < prev next >

Wrap

Text File | 1996-10-05 | 34.4 KB | 785 lines

TNOS Release Notes - Release 2.20 Brian A. Lantz, brian@lantz.com v1.00, 05 October 1996 These are the DRAFT Release Notes for release 2.20 of TNOS. Hope- fully, this list of changes will give you an idea of the scope of work that has occured since the release of TNOS 2.10. ______________________________________________________________________ Table of Contents: 1. Bug Fixes 2. Improvements and Enhancements 3. Minor Changes 4. Remaining Known Bugs 5. To-Do List ______________________________________________________________________ 1. Bug Fixes The following bugs have been squashed. o Fixed FTP put security hole (UNIX) If creating a new file, the directories write permissions were not being used to determine whether or not the action would be permitted. o AXUI callsign buffer expanded in size o Fixed a buglet that crashed the system w/long nickname in convers Only occurred with a LONG nickname when executing the '/cut' command. Obscure, but there..... o Fixed a few assorted buglets that weren't reported before 2.10 :-( o Fixed crash if corrupted wpages files are expired o Fixed a subtle bug affect the pathname() function This only affected 'finger' when using the '-d dirname' command line option, and then not always. o Fixed a minor problem with forwarding using an area rewrite If multiple messages were being sent during an FBB or XFWD bundle, then only the first address was being rewritten...... o Fixed problem with a CC: to a public area If you send a 'SP' BBS message (or 'SC') and end up with a CC: to a public area it has an 'X-BBS-Type' line defining it as personal, when it should be bulletin. This only is examined when forwarding PBBS traffic. There used to be code in TNOS (from JNOS) that made the 'X-BBS-Type' line *the* authority on the message's type. Now, if a message is in a public area, it is a bulletin, and the 'X-BBS- Type' value is ignored (i.e. a 'B'ulletin will not be changed to a 'P'ersonal). If it is public, it cannot be personal. This does NOT prevent having the reverse, that is messages in private areas (maybe a private storage area for an individual PBBS's forwarded messages) being sent as bulletins. Also, in doing this, I noticed that you COULD have a message in a 'nts' area that sometimes would NOT be sent as a 'ST' message. This was also fixed. o Fixed displaying parameter strings with a '\r' Now, if you define a parameter string (like 'ax25 bctext') to be a multi-line string with a '\r', the output to the screen or the remote user will be as expected, i.e. it will look the same as '\n'. o Fixed problem with 'editheader' and messages without a X-BBS-Type o Several unreported RIP bugs found (in LINT'ing) related to broadcasts o Fixed where some HTTPPBBS accesses weren't removing 'users' when done o Added a fix for supressing Polled Kiss polls on multidrop kiss o Fixed convers compatibility problem with NON-TPP servers If the callsign/nickname combo's is larger than 9 characters, this will prevent a Jnos host that is linked in from hearing what that person is saying. Now when speaking with a non-TPP compatible system, the nickname should be striped off (if one was set) before passing the data to the brain-dead server. o Fixed an evasive buglet in FBB forwarding code At times, after sending a transaction, TNOS would send another one, without allowing the remote side to take their turn. Though this has happened since FBB forwarding was added, it happened so infrequently is was hard to pin down, and even when spotting it, there didn't seem to be a pattern to it. Well, there was ;-) It turns out that if all messages in the negotiation bundle were rejected, that's when this occurred. The first line of the remote's negotiations would get eaten, and then TNOS would start a new negotiation, in which it THOUGHT that the remainder of the remote's negotiation was an invalid response. All fixed now! o Fixed a rare bug with the at command o Fixed a kiss trace buglet, for multidrop kiss o Fixed buglet where some forwarded personal messages weren't deleted They were removed from the forwarding queue, but not marked as deleted messages This only affected FBB and XFWD sessions. This normally didn't happen, except when a message was rejected, for whatever reason. o Fixed a discovered memory leak with FBB and XFWD sessions o Forward file locking fixed If a record got added into a *.fwd file when a forwarding session is concluding, sometimes the new record STILL got missed, and the *.fwd file would get deleted, losing that new record. Only happened if the new message was in the SAME area as the area last processed. Rare, but needed to be addressed. o Fixed a XFWD trace buglet, with incoming messages Thanks to a typo, if the 'forward xtrace' is on and a new message comes in, there was a crash. o Corrected occasional delay in noticing new messages in PBBS queues While not bad previously, new messages MIGHT not have caused an immediate rescan of the queue on the very next negotiation for FBB or XFWD sessions. Now this should always rescan on the next negotiation. The net result is that (for example) if a new personal message comes in on one forwarding session that is queued for another PBBS that is also actively forwarding, then that message will go out on the next negotiation (assuming that you have the personal areas located before the public areas in that PBBS's forwarding entry in the 'forward.bbs' file). o Added Gareth's fix for incomplete nntp file crashes o Fixed a parsing bug with incoming XFWD sessions o Fix for possible string overflow during command line expansion o LONGSTANDING DNS buglet found! The DNS code had a subtile bug, which allows overrunning a buffer if the address being queried returned a LONG response. This only occured if the DNS was serving for others, and NOT for local usage. This one probably accounted for the assorted DNS quirks, as well as some (possibly ALL) of the strangely corrupted memory problems. For example, if you queried a TNOS site (connected to the Internet) for the address 'mx1.compuserve.com', then you would PROBABLY would have crashed the system, 1 out of every 3 or less attempts. But a query on a simpler address (such as 'lantz.com') would NEVER crash it. The 'mx1.compuserve.com' address returns *10* 'A' records, and uses about 2K of space to store it, when previously only 1K was being allocated. If your 'domain dns' is off, this would NEVER affect you. It was not in the mainline DNS code, just in the code used when TNOS was acting as a server for others. The original RFC stated that 512 bytes should be the MAX that is returned in a DNS UDP packet, but this seems (at a quick glance) to be being ignored (deliberately or accidently) by every server I checked. For the time being, this has been changed to 4K, which should be FAR more than enough. This will need to be revisited when I've had time to investigate whether the RFC is obsolete or not. o Fixed a problem sending ReturnReceipts to incomplete messages There would be a crash if trying to send a ReturnReceipt to a message that didn't contain a 'To:' header or a 'Subject:' header. o Fixed a PBBS 'vm' crash with more than 30 messages o Fixed a buglet with 'smtp kick <host>' o Fixed a longstanding startup file/DNS problem Several commands take a hostname or an IP address. If these are used in the startup file, they must be used with the ip address, NOT the hostname. This is regardless of whether or not the DNS is already configured. The reason is that the multitude of command that call the resolver, do so expecting that they will NOT be swapped out. This is NOT so with the resolver, as a DNS response can take a while. In the past, this led to a quick crash, as the commands parameters got freed before the command was finished with them. In this release, the restriction of no hostname usage in the startup file remains, though now the line causing the error will report a useful message, and a crash will NOT occur. If you REALLY need to have a command in the startup file using a hostname, you can (for example) do a: nntp add ko4ks 3600 * like this: at now+0001 "nntp add ko4ks 3600 *" It will delay it's action by 1 minute, though. o Fixed incorrect paging in 'nntp read' newsgroup reader o Fixed XFWD email 'PBBS' name and dups scanning Previously, all received email from XFWD sessions came in as if it came from a PBBS named 'import', since it was being processed by the import code. Now it properly identifies the PBBS sending it. Also, it was discovered that the setup for the import call did not set enough options to allow the message to be properly scanned for R: line dups, if ALTERBID is enabled. Now this is fixed. o Fixed NNTP code that was improper in view of RFC977 If an 'IHAVE' failed, the connection was aborted. RFC977 states that if a server has a problem with an 'IHAVE', it can report an error, or just drop it silently. It should NOT need to abort. And all xNOS NNTP servers would have then gotten into a loop, as an aborted session did not update the 'poll' files polling time. This would NOT remove the erring message from those that it would try to send (unsuccessfully) next time, in a loop until humans intervened. Aside from that, aborting due to a single rejected posting (via IHAVE) is NOT efficient, as the two sites MAY only connect once or so a day. Postponing VALID news articles because of one INVALID one is not acceptable. If PBBS forwarding aborted a session due to rejecting a single message, SYSOPs would be screaming ;-) The loop had already been found and fixed in this TNOS release, but now the bad message sent via 'IHAVE' will not cause an abort. o Added incoming negotiations from XFWD to log file (an oversight) o Added code to delete incomplete PBBS messages from forwarding queues If the forwarding code sees a message without a 'To:' and 'From:' field, then that message is deleted from the forwarding queue. Previously, this message could not be forwarded (obviously) but it also did not get removed from the forward queues, without sysop intervention. o FOUND THE ELUSIVE "gateway no-timeout disconnect" bug! o Added a few pwait()'s to the fwding code, it was greedy at times o Also refresh 'pbbs tdisc' counter during gatewaying for incoming data o PBBS gatewaying now yields to 'pbbs maxtimer' setting, if used o All the above items included in beta release 2.20b1 o Fixed NNTP buglet with multiple "GMT"s in a NEWNEWS command line o Fixed NNTP bug in code gatewaying PBBS->NNTP messages o Fixed a bug in the IMPORT code o Fixed an FTP server buglet (in Unix) The security patches weren't complete, and you COULD do an 'ls' on a directory which didn't allow reading in it's permissions. o All the above items included in beta release 2.20b2 o Fixed a buglet in the NNTP code that could trash the 'domain trans' setting 2. Improvements and Enhancements The following optimizations and improvements have occurred. o Added a 'security createsecure' command, for securing new file creation This boolean command sets whether the 'security createperms', 'security createuid', and 'security creategid' commands are to be used. o Added a 'security createperms' for new file creation permissions (UNIX) o Added a 'security createuid' for new file creation user ID (UNIX) o Added a 'security creategid' for new file creation group ID (UNIX) o Added a 'MINIDLE' attribute to the PBBS forward.bbs for each entry For each BBS in the forward.bbs file, their MINIDLE attribute is set to the value of the 'forward minidle' command. This value can be overridden for each BBS by setting it's own 'MINIDLE' attribute. This allows you to set some BBSs with short retry intervals, while other ones can be set with long intervals. By using this, and setting the 'forward timer' to a short value, you can have different connection intervals for each BBS. o Added to forwarding, code to limit time of fwding session o Added a 'forward limittime' command to set default max session time o Added a forward.bbs LIMITTIME attribute to override default o TNOS/DOS no longer supports BorlandC - Now uses DJGPP! Many reasons for this change: 1. This is a FREE compiler 2. It is easy for anyone to acquire 3. It is the MSDOS port of the GNU C compiler, so the same compiler will be used for both Unix and MS-DOS compiles. 4. The source tree will be able to be simplified 5. It contains its own DOS extender, allowing a linear memory map (no 640K conventional memory limitation) 6. It will use as much memory as you have, as long as you have a memory manager that supports DPMI (and a free one is available for use with DJGPP applications) 7. TNOS/DOS users will be able to compile in EVERYTHING that they want! NO MORE 'DGROUP exceeds 64K' compiler errors. By the time this release goes public, all you need to know will be put together to make it painless for the user or the individual who WANTS to compile their own. There will be no NEED to compile your own, though. And as of this release, I WILL resume making production MS-DOS executables available, though only one will be supplied, with most everything compiled. And Team TNOS will be MORE than glad to do custom compiles for those who wish a smaller executable, if needed. Custom compiles with DJGPP are no more effort than under Unix. Some Borland-specific code has already been removed, and more will soon. TNOS is now a BorlandC-free zone ;-) o Added a 'forward reload' command This should allow a way to eliminate the occasional crash if a BBS was added or deleted from the 'forward.bbs' file and the system wasn't aware of that change. This is NOT needed for changes within an already defined PBBS in the file, but should be executed when PBBSs are added or deleted to a running system, as soon as the change is made. Using this command also clears the 'forward laston' times and will affect the 'forward minidle' and MINIDLE attributes for the PBBS defined in the forward.bbs file. None of these is terminal; this is mentioned as a caviat. o Added logic to forwarding code in determining if BBS is connected Previously, if a user was connected to the PBBS with the same name as an outbound forwarding BBS, the session would be skipped, even if this was the actual USER of that remote BBS visiting your system. While that USER was connected, traffic would backup on your system. This also was the same if the remote BBS used your system to gateway to forward to another system. Now if the USER seems to be on the system, the data from that user is analyzed to see if we have received a PBBS SID. If not, then this cannot be a forwarding session (at least, not yet), and the outbound connection is allowed. While their is the outside chance of an inbound and an outbound both occuring at the same instant, they would be no problem in that happening. o Added PPPIPIP option 3, for use with Windows NT servers. o Added a 'pbbscmd norreceipt' command to disable ReturnReceipt responses o Added expiration of NNTP newgroups New commands are: nntp expire articles <expiry in days> (default 28) nntp expire bids <expiry in days> (default 56) nntp expire now kicks the nntp expire process into action. The first two determine the age of articles and bids to be expired by the 'nntp expire now'. To do the expiration automatically at a set time, add a cron entry for it. o Added a 'nntp rline' command - Thanks Gareth Determines whether R: lines are preserved when moving PBBS messages to NNTP. When off, R: lines passing through the pbbs->nntp gateway are stripped of their R: Lines, and the BBS callsigns are added to the Path: line. When on: R: lines are left in place, and BBS calls are not added to Path. The default is on. The R: line stripper only operates on bulletins gatewayed from your PBBS areas on your TNOS. o Added a 'forward biduknos' command This (if enabled) will create local bids of 'xxx_<host>@hamradio' rather than 'xxx@<host>'. For messages forwarded in via PBBS forwarding, the bids will be 'xxxxxx@hamradio' rather than 'xxxxxx@<remotebbs>.bbs'. This is for compatibility with UKNOS, which does it different than all other NOS's. o Added code to reject messages with non-ASCII addresses Since the PBBS spec makes these required to be ascii, TNOS will now reject all non-ascii to and from addresses, and BIDs. Some were received here with both callsigns as 6 '0xff' characters and all the data characters were the same. Now those invalid messages will be refused, at least with FBB-style forwarding. o Added two NNTP subcommands 'nntp pbbs2nntp' and 'nntp nntp2pbbs' Each of these command determine whether or not one side of the new NNTP-to-PBBS gateway is active. If 'nntp pbbs2nntp' is on, then all PBBS bulletins and selected personal messages will be gated into NNTP. If 'nntp nntp2pbbs' is on, then most NNTP messages will be gated into the PBBS message areas The PBBS-to-NNTP handling uses a 'etc/news2mail' file. The format is: news.group.name toaddress [ distribution ] Any amount of white space can separate any of the fields, and comments can be placed in that file by using a '#' as the first character on the line. Blank lines are also ignored. If the user part of the address (part before the '@') is found in the file as one of the 'toaddress' fields, then the message will be sent to the 'news.group.name' on that line. If an optional 'distribution' is given, then it will be used rather than the default (discussed in the next item). The 'distribution' string (if given) must be the complete distribution name. If the 'distribution' is '-', then the distribution will be created as described in the next paragraph. If the address is NOT found in the 'news2mail' file and it is NOT a personal message area, then a newgroup name will be made by appending the user part of the address to 'ampr.bbs.'. If a host portion of the address was given (the part after the '@'), then the distribution will be 'bbs.' with the host portion appended. Personal messages CAN be gated from PBBS to NNTP, but only if they have an entry in the new2mail file. A typical entry would be: ampr.mailbox.sysop sysop - All PBBS forwarded messages with a 'Message-Id:' ending in '.bbs' will be converted to <BID@hamradio>, to accommidate for consistency in Message IDs, and to prevent dups. NNTP-to-PBBS gatewaying uses the same 'news2mail' file, placing messages into the PBBS if they are found in that file. The 'toaddress' field is used as the user name and the host part of the PBBS address is the last portion of the distribution header line in the news article. If the NNTP newsgroup is NOT found in the 'news2mail' file, but the newsgroup begins with 'ampr.bbs.', it is gated into the PBBS, using the last portion of the newsgroup name as the user portion of the address and the host part of the PBBS address is the last portion of the distribution header line in the news article. Message ID's of news articles ending in '@hamradio' will be changed to '@nntp.bbs'. All other message ID's will remain intact, and will be treated by the PBBS forwarding code as it always has. All news articles NOT in the 'news2mail' file that do not begin with the 'ampr.bbs.' prefix are NOT gated into the PBBS. o Added a 'nntp defaultdist' command This sets the default distribution used by PBBS-to-NNTP gatewaying, if the address has a matching entry in the 'news2mail' file and does not specify a specific distribution. This has no effect on messages not found in the 'news2mail' file or on NNTP-to-PBBS gatewaying. The default for this is 'bbs.www' for worldwide distribution. o Added a 'nntp trace' command - with some activity traced o Added a pre-defined 'fwd_queue' finger target Provides the same info as the Command Session 'forward summary' or the PBBS 'if' commands. o Added a NNTPFILTER compilation flag This uses the 'etc/wordhold.dat' file (the same one as for HOLDMODS) to record words that are unacceptable for NNTP articles. Any incoming articles (POST'ed or IHAVE'ed) will be checked against this list (if the NNTPFILTER flag is compiled in), and if any are found, then the article will be dropped, reporting the error. This is a long needed addition to the NNTP server, with the Amateur licensing regulations varying as much as they do from country to country! o Added another NEW feature, that COULD be interesting! Added an new server, which can be used in many different ways. I like these kinds of additions, as I know that users will find many ways to use this that I never could have imagined! (Like the Tscript language) There is now a FIFO server (sorry, TNOS/Unix only), which (when started) creates two fifos, and input one and an output one. You can (from Unix) feed commands to the Command Session via TNOS's input fifo, and if output is generated from the command, you can read it from TNOS's output FIFO. The FIFO to input commands into TNOS is 'spool/fifo_in' and the output FIFO from TNOS is 'spool/fifo_out'. You start the FIFO server with a simple 'start fifo [trace]'. If the 'trace' parameter is omitted, then diagnostic tracing to the Command Session is disabled. You stop the FIFO server with 'stop fifo'. This came from my getting tired of occasionally needing to restore the parameters to a KISS TNC, when minor power outages occur (the computers here are all on UPS's, but the TNCs are not. It gets to be a regular occurance in Florida, during thunderstorm season. I got tired of having to do a 'grep param' on my autoexec file, grabbing it in my paste buffer with the mouse, toggling to the TNOS Command Session, and pasting it. I wanted an easy way to send the output of the 'grep' directly into TNOS. This can do that.... Reading TNOS's output FIFO can be a bit confusing, if you are dealing with an application that partially buffers input queues. The 'tail -f' SHOULD work, but doesn't (unless you 'stop fifo' from TNOS). But a simple 'cat /nos/spool/fifo_out' works fine. o Added a new "-m" command line option, to display Feature Flags info This option simply returns a hexadecimal string, representing the compiled feature flags of that executable, then it completes execution. This hex string contains one bit for each compilable flag, which is set if the Flag was set, or cleared if the flag was cleared. This can help simplify reporting which features are in an executable. o Added a new executable, 'tnosmap', which decodes the '-m' output The output of this simple executable is a list (one per line) of all the compiled Feature Flags for the given string. This application can either take a single hexadecimal string, or the actual output from the 'tnos -m' command, which is the hex string preceeded with a label. Unix users can easily tie this command to the previously mentioned option, using: tnosmap `tnos -m` o All the above items included in beta release 2.20b1 o All the above items included in beta release 2.20b2 o Added the FORTH interpreter code from SM0RGV Not sure how useful it will be, but you can compile it in! ;-) The forth.c file compiles with two warnings, though. o Added a new conditional processing directive to forward.bbs syntax This new one, 'if DAYOFWEEK = xx' or 'if DAYOFWEEK = xx-yy' can allow you to limit sections of a forwarding entry to only certain days of the week. 3. Minor Changes The following minor changes have occurred. o Added code to set newly created files owner, group and permissions (UNIX) This is for both FTP 'put's and PBBS 'uploads'. Owner is set to the value of 'security createuid', group is set to the value of 'security creategid', and the file's permissions are set to the value of 'security createperms', *IF* the 'security createsecure' command is set to 'on'. o Renamed the 'security ftpuid' command to 'security accessuid' o Renamed the 'security ftpgid' command to 'security accessgid' o Added code to the PBBS download command to also honor security (UNIX) The 'security accessuid' and 'security accessgid' values are used (as with the FTP server) to determine whether or not the user has permission to download the file, based on the UNIX file permissions, as they pertain to the secured user/group o Removed the 'dump' command from UNIX version Easy way to core dump, and anyway, who REALLY would use this with GDB around ;-) o Added a new flag 'STRICT_HTTPCALL' for enforcing valid calls w/HTTPPBBS o Added use of security 'amprperms' and 'nonamprperms' w/HTTPPBBS o Added a PBBS 'motd' command, to redisplay the 'pbbs motd' string o Added code to the PBBS forwarding to prevent useless outgoing connects It the past, if there were messages queued in the forward file for a PBBS, but they were all still being held for sysop review or all of them were deleted messages, then a connection would be made, even though there was no traffic that would be outgoing on that connection. This made it work like a polled connect, but was actually an unwanted outgoing connection. Now these useless outgoing connects are suppressed. Also added code in that section to remove the '.fwd' file if all the remaining entries in the queue are for messages already deleted from the system. o Added code to help prevent crashes when parsing a corrupted domain.txt I don't know if this will prevent all of the problems, but many sources of problems when parsing a corrupted domain.txt file have been caught. When these cases are found, a message is logged to the log file, to help find the problem, listing the kind of DNS line it encountered that had the error. o Several more files LINT'ed o Added a 'smtp kick' at end of outbound forwarding sessions o Added code to append 'ampr.org' to abbreviated hostnames in PBBS 'send' This applies to email addresses like 'ko4ks@ko4ks'. When seen, the address will properly be changed to 'ko4ks@ko4ks.ampr.org', so that rewrites that treat SMTP addresses differently can act properly. See next entry! o Added 'pbbs maildomain' command Depending on the system, some TNOS machines prefer SMTP connections (if possible) and others PBBS connections. This command allows you to override the default (of PBBS addressing) and lets DNS hostnames be used instead. This only comes into play for addresses like 'user@host'. In cases like that, the 'host' portion of the address is looked up in both the white pages and the DNS (as 'host.ampr.org'). If only one gets found, that one will be used. If BOTH are valid destinations, then this command will be used to determine which one is used. If 'pbbs maildomain' is on, then the ampr.org address will be what is used; otherwise the white pages one will be used. If a full DNS hostname is given or a complete PBBS haddress is used, then this command is not used. The 'pbbs maildomain' command is only used to complete the address used on addresses like 'user@host'. o Added code to prevent a useless PBBS connection following a failed one If a failed PBBS session results in all remaining messages in the queue being marked as aborted, then the next session would end up skipping those on the first scan of the next connect (as it should), but with XFWD (or FBB if the remote site had nothing to send) this would result in a useless connect, as those messages wouldn't try to get out the door at all on that session. If other messages were in the queue, this would work as planned, but this was a special case. o MANY more files LINT'ed o Added NNTP XHDR and XOVER enhancements from JNOS o Removed all 'C' __ARGS() and __FARGS() macros from the source tree While not noticable to the user, this cleans up the source tree a lot. It was a lot of work, but past due. This assumes compiling TNOS with an ANSI C-compatible compiler, which is no longer an issue, since all TNOS support is for GCC compilers. In this day and age, it's not really an issue, anyway. o Added a 'chat' PBBS command, an alias for the 'Operator' command I THOUGHT that this had been in there for a long time, but noticed that it wasn't. o Changed the output of 'nntp active' to two newsgroups per line o Corrected the NNTP usage of GMT time The NNTP RFC (977) specifies that the times given to commands like NEWNEWS are to be in the SERVER's localtime, or should be in GMT time, with 'GMT' appended to the string. The NNTP server could handle incoming clients using 'GMT' strings, but would always use ITS localtime when talking to a remote server. This is fine if both are in the same time zone, but otherwise is wrong. Now TNOS's NNTP server will use GMT strings when acting as a client. o LINT'ing completed o All the above items included in beta release 2.20b1 o All the above items included in beta release 2.20b2 o Added DNS patches from JNOS to allow CNAME responses to recurse 4. Remaining Known Bugs The following are known bugs that will be addressed in the near future. These may or may not be fixed before the next release is made available. 1. The proxy server scripts do not seem to work properly There is a problem, that is being looked into, which seems to be related to calling scripts from within scripts (which proxy.scr DOES). 2. None other at this time.... ;-) 5. To-Do List The following are things on the author's 'to-do' list that are being considered for this or a future release of TNOS. These may eventually be done, but not necessarily by the next release. 1. Finish porting the Packet driver into the new MSDOS sources At the moment, the Packet driver is not supported for the DJGPP compiles. Shouldn't take too long to get ported, though.... 2. Complete the spec and coding of the non-IP HTTP PBBS interface 3. Investigate incorporating into TNOS a userfs extension This would allow *any* Linux (and possibly other Unix) program to open a file and access certain TNOS features. For instance a terminal program like minicom could open a device: /tnos/connect/lan/k0zxf/ko4ks-1/813044 and do the equivalent to 'connect lan k0zxf ko4ks-1 813044'. You could incorporate a copy of your current usage stats into a email message in Pine, by simply inserting a file named /tnos/stats/usage/general. 4. Add capability to allow use of OS commands This includes finishing the incomplete 'pipe' command in the Unix release. Due to the obvious restrictions of MS-DOS (memory, etc.), this WILL be considered for Unix version only. 5. Add better support for PBBS<->Internet mail address translation The 'translate' file and improved handling of aliases is a START, but more work needs to be done here. Maybe a 'translate.out' file... 6. Still better handling of AUTO/LOCAL ax25 routes Improvement by making an ax25 route entry part of the connection block, using this unique AUTO route for this connection only. 7. Support (optimization) for ncurses 1.9.x for performance 8. Color support output to Unix console The various color commands don't work with Unix and curses. Annoying, but just possible unexpected output. No crashes. 9. Consider adding a 'R x - x' syntax to the BBS read command 10. Consider adding IP MASQ support 11. Add code to allow a TIP socket type, for use with LL Modems 12. Tweek the WPages code a bit Need to improve the code that insures that the wpagebbs entries are correct, of the proper length, and actually look like hier addresses. Also, make the expiring of WPages files less fragile if the file has become corrupted. 13. Check into duplicate entries in the WP files While not harmful, the WPages routines SHOULD be overwritting existing entries, NOT creating new ones. 14. Consider adding intelligence to convers links The idea being that if there are no incoming links, and no local users, that the remote outgoing link would be brought down until this changed. 15. Consider added auto7+ detection